El prop≤sito de este documento es explicar el IP-spoofing a las masas. Solamente se requiere un poco de conocimiento prßctico de Unix y TCP/IP para entenderlo
sin problemas. Oh, y que no seas un in·til...
IP-spoofing es una compleja tΘcnica de ataque constituida por varias partes. (En la actualidad, IP-spoofing no es el ataque, sino s≤lo un paso en el ataque. El ataque es actualmente un aprovechamiento de la relaci≤n entre dos trusted hosts. Sin embargo, en este documento, IP-spoofing irß referido al ataque completo.) ExplicarΘ la tΘcnica en detalle, incluyendo informaci≤n relevante sobre sistemas operativos y redes.
[SECCI╙N I. INFORMACI╙N PREVIA]
-- [Los Protagonistas]--
A: host objetivo
B: host con el que se establece la relaci≤n ("trusted host")
X: host no alcanzable
Z: host atacante
(1)2: host 1 disfrazado como host 2
--[Los Esquemas]--
Hay muchos esquemas en el documento y tienen que ser interpretados como el siguiente ejemplo:
tick host a control host b
1 A ---SYN---> B
tick: un paso de tiempo. No hay distinci≤n entre *cuanto* tiempo pasa entre cada paso, simplemente que el tiempo pasa. Generalmente no es mucho.
host a: Un sistema participando en una conversaci≤n basada en TCP.
control: Este campo muestra cualquier conjunto de bits de control relevantes en la cabecera de TCP y la direcci≤n que estßn tomando los datos.
host b: Un sistema prticipando en una conversaci≤n basada en TCP.
En este caso, en el primer paso el host a le estß enviando un segmento TCP al host b con el bit de SYN ac-tivado. A menos que se indique lo contrario, no nos importa la porci≤n de datos de dicho segmento TCP.
--[Trusted Hosts]--
En el mundo del Unix, la confianza se da fßcilmente. Digamos que tienes una cuenta en el sistema A, y otra en la mßquina B. Para facilitar ir de una a la otra con un mφnimo esfuerzo, deseas establecer una relaci≤n o uni≤n entre ambas. En tu directorio home en A creas un archivo .rhosts: `echo "B nombre-de-usuario" >
~/.rhosts┤ En tu directorio home en B creas otro archivo .rhosts: `echo "A nombre-de-usuario" > ~/.rhosts┤ (Como alternativa, el root puede establecer una configuraci≤n similar en /etc/hosts.equiv, la diferencia estß en que entonces serφa a nivel del host entero, no s≤lo a nivel individual.) Ahora, puedes usar cualquiera de los comandos r* sin necesidad de tener que perder el tiempo con verificaciones de passwords. Estos comandos permitirßn la autentificaci≤n en base a las direcciones, lo que ofrecerß o negarß el acceso dependiendo de la direcci≤n IP del solicitante.
--[Rlogin]--
Rlogin es un simple protocolo cliente-servidor que utiliza TCP como medio de transporte. Rlogin permite a un usuario identificarse (hacer login) remotamente desde un host a otro, y, si el host objetivo confφa en el otro (ver apartado anterior), no nos pedirß ning·n password. En lugar de esto habrß comprobado la identidad del cliente (nosotros) analizando nuestra direcci≤n IP. Por tanto, como en el ejemplo de arriba, podemos usar rlogin para hacer login remotamente desde A a B (o viceversa) y no nos pedirßn ning·n password.
--[Internet Protocol (IP)]--
IP es el protocolo de red menos fiable de todo el sistema TCP/IP. Posee dos campos de encabezamiento de 32-bits para la informaci≤n de las direcciones. IP es tambiΘn el mßs empleado de todos los protocolos TCP/IP ya que casi todo el trßfico TCP/IP estß encapsulado en datagramas IP. El trabajo del IP es enrutar paquetes de la red. No ofrece ning·n mecanismo de comprobaci≤n (es un protocolo "sin conexi≤n"). IP simplemente envφa datagramas y confφa que lleguen intactos a su destino. Si no lo hacen, IP puede intentar enviar un mensaje ICMP de error al origen, aunque por supuesto este paquete tambiΘn puede extraviarse. (ICMP significa Internet Control Message Protocol, y se usa para informar sobre las condiciones en las que se encuentra una red y sobre los errores que se van produciendo al IP y a otros protocolos). IP no tiene ning·n medio para garantizar el envφo de paquetes. No mantiene ninguna informaci≤n sobre el estado de la conexi≤n. Cada datagrama IP es enviado sin niguna relaci≤n con el ·ltimo enviado o el siguiente a mandar. Esto, unido al hecho de que es sencillφsimo modificar la
pila de IP para permitir la elecci≤n de una direcci≤n IP arbitrariamente en los campos de origen (y de destino) convierten al protocolo IP en algo fßcilmente modificable.
--[Transmission Control Protocol ]--
TCP es el protocolo orientado a la conexi≤n, el protocolo de transporte en el que se puede confiar plenamente dentro del sistema TCP/IP. Orientado-a-la-conexi≤n significa simplemente que los dos hosts que participan en una discusi≤n deben establecer previamente una conexi≤n antes de que los datos puedan liarse a tortas. La seguridad se consigue a travΘs de diferentes modos, pero los dos que nos conciernen ahora mismo son secuenciaci≤n de datos e identificaci≤n. TCP asigna n·meros
secuenciales a cada segmento e identifica todos los segmentos de datos recibidos desde el otro extremo. (Se revisa la secuencia de n·meros, no los segmentos en sφ). Estas caracterφsticas hacen que TCP sea mucho mßs difφcil de trucar que IP.
--[N·meros Secuenciales, Identificaciones y otras indicaciones]--
Dado que TCP posee una seguridad bastante aceptable, debe ser capaz de recuperar datos perdidos, dupli-cados, o fuera-de-servicio. Asignando una secuencia de n·meros a cada byte transmitido, y requiriendo una identificaci≤n para cada uno recibido del extremo opuesto, TCP puede garantizar una transmisi≤n sin errores. El extremo receptor utiliza la secuencia de n·meros para asegurar el orden correcto de los datos y eliminar bytes duplicados. Los n·meros secuenciales del TCP se pueden imaginar como contadores de 32-bits. Se encuentran en un rango desde el 0 hasta el 4.294.967.295. Cada byte de datos intercambiado en una conexi≤n TCP (junto a otros indicadores) va secuenciado. El campo del n·mero secuencial en la cabecera TCP contendrß el n·mero secuencial correspondiente al *primer* byte de datos en el segmento TCP. El campo del n·mero de identifi-caci≤n (ACK) en la cabecera TCP muestra el valor del siguiente n·mero secuencial *esperado*, y tambiΘn identifica *todos* los datos hasta este n·mero de ACK menos uno.
Para el control del flujo, TCP envφa un paquete para decirle al otro extremo cußntos datos puede buffear. Dado que este paquete es de 16 bits, se puede notificar un mßximo de 65535 bytes. El objetivo de este mΘto-do es enviar una notificaci≤n desde un TCP al otro sobre la amplitud de la secuencia de n·meros a emplear de manera que sea aceptable.
Otros indicadores en la cabecera TCP a mencionar son RST (reset), PSH (push) and FIN (finish). Si se re-cibe un RST, se corta inmediatamente la comunicaci≤n. Los RSTs se envφan normalmente cuando un extre-mo recibe un segmento que simplemente no tiene relaci≤n con la conexi≤n que estß establecida (veremos un ejemplo abajo). El indicador PSH le dice al receptor que pase tan pronto como sea posible todos los datos que se han ido almacenando a la aplicaci≤n correspondiente. El indicador FIN es la manera en que una aplica-ci≤n comienza el amable cierre de la conexi≤n (el corte de una conexi≤n es un proceso de 4 (direcciones). Cuando un extremo recibe un FIN, lo ACKea (autentifica) y ya no espera recibir mßs datos (sin embargo el envφo es todavφa posible).
--[Estableciendo una Conexi≤n TCP]--
Para poder intercambiar datos usando TCP, los hosts deben establecer una conexi≤n. TCP establece una conexi≤n siguiendo un proceso de 3 pasos llamado el Saludo de las 3 direcciones. Si la mßquina A estß utilizando un cliente de rlogin y desea conectar a un daemon de rlogin en la mßquina B, el proceso es el siguiente:
fig(1)
1 A ---SYN---> B
2 A <---SYN/ACK--- B
3 A ---ACK---> B
En (1) el programa cliente le estß diciendo al servidor que quiere una conexi≤n. Este es el ·nico prop≤si-to del indicador SYN. El cliente le estß diciendo al server que el campo de secuencia numΘrica es vßlido, y que deberφa ser comprobado. El cliente configurarß el campo de secuencia numΘrica en la cabecera TCP a su ISN (Initial Sequence Number, n·mero inicial de la secuencia). El server, al recibir este segmento (2) responderß con su propio ISN (por lo tanto el flag SYN estß activado) y una autentificaci≤n (ACK) del primer segmento enviado por el cliente (que serß el ISN-del-cliente + 1). El cliente entonces ACKea (autentifica) el ISN del servidor (3). Ahora ya puede tener lugar la transferencia de datos.
--[El ISN y el Incremento de los N·meros Secuenciales]--
Es importante entender c≤mo son elegidos los n·meros secuenciales inicialmente, y c≤mo cambian con respecto al tiempo. El n·mero secuencial inicial se cambia a 1 cuando el host se inicializa. (TCP llama a esta variable "tcp_iss" dado que se trata del n·mero secuencial inicial *de envφo* (initial*send* sequence number). La otra variable de n·mero secuencial, "tcp_irs" es el n·mero secuencial inicial *de recepci≤n* (initial *receive* sequence number) y se establece al crearse la conexi≤n de 3
direcciones que tratamos antes. Pero no nos vamos a preocupar por las distinciones entre las dos variables). Esto da a entender un error, y se autentifica como tal con el correspondiente comentario en la funci≤n tcp_init() de d≤nde aparece. El ISN se incrementa en 128.000 cada segundo, lo que provoca que el contador de ISN de 32-bits quede agotado cada 9.32 horas si no se establece ninguna conexi≤n. Sin embargo, cada vez que se establece un connect(), el contador es incrementado en 64.000.
Esto es asφ por una importante raz≤n, y es hacer mφnimo el riesgo de que datos de una vieja encarnaci≤n pasada (jeje, quiero decir, desde el mismo cuarteto de direcciones-IP y puertos TCP locales y remotos) de la conexi≤n actual pueda llegar y joder las cosas. Aquφ se aplica el concepto del tiempo de espera de 2MSL, pero no lo analizaremos porque no es el objetivo de este documento. Si los n·meros secuenciales fuesen elegidos al azar cuando llega una conexi≤n, no se podrφa garantizar que esos n·meros secuenciales fuesen distintos de los empleados en una conexi≤n anterior. Si una porci≤n de datos quedase retenida en mitad de su recorrido y despuΘs consiguiese llegar a su destino interfiriendo con el reenvφo de la vieja conexi≤n, ten por seguro que se joderßn las cosas.
--[Puertos]--
Para garantizar el acceso simultßneo al m≤dulo de TCP, TCP provee un interfaz de usuario llamado puerto. Los puertos son utilizados por el kernel para identificar procesos de red. Y Θstos son estrictamente entidades de transporte (que es lo mismo que decir que al IP le importa un pimiento su presencia). Junto a una direcci≤n IP, un puerto TCP forma lo que hemos llamado extremo de una comunicaci≤n de red. De hecho, en un momento dado *cualquier* conexi≤n de Internet puede ser
descrita por 4 n·meros: la direcci≤n IP de inicio y su puerto , y la direcci≤n IP de destino y el correspondiente puerto de destino. Los servers suelen ce±irse a puertos corrientes para que puedan ser localizados a travΘs de puertos estandar en sistemas diferentes. Por ejemplo, el daemon de rlogin se encuentra en el puerto TCP 513.
[SECCI╙N II. EL ATAQUE]
...El diablo encuentra trabajo para las manos que no hacen nada...
--[Antes de nada...]
El IP-spoofing se compone de varios pasos, que resumirΘ brevemente ahora y luego analizaremos con mßs profundidad. Primero, se elige el host objetivo. A continuaci≤n descubrimos un indicio de "confianza" con otro host, es decir, nos lleva a un trusted host. Entonces se desactiva el trusted-host, y se hace un muestreo de los n·meros secuenciales de TCP del objetivo. Se usurpa la personalidad del trusted host, se averiguan los n·meros secuenciales correspondientes, y se intenta la
conexi≤n a un servicio que s≤lo requiera identifica-ci≤n basada en direcciones. Si sale bien, el atacante ejecuta un simple comando para dejar una puerta trasera en el sistema.
--[ Cosas Necesarias ]--
Hay varias cosas que se necesitan para llevar a cabo esta tΘcnica:
- cerebro, mente, o cualquier otro dispositivo pensante
- host objetivo
- trusted host
- host atacante (con acceso de root)
- software de IP-spoofing
Generalmente el ataque se hace desde la cuenta root del host atacante contra la cuenta de root del objetivo. Si el atacante se va a tomar todas estas molestias, serφa est·pido no aspirar como mφnimo a ser root. (Dado que se necesita ser root para ejecutar el ataque, esto no deberφa ser problema).
--[ IP-Spoofing es un "Ataque Ciego"]--
Un factor que muchas veces no se analiza pero que es crφtico en el IP-spoofing es el hecho de que el ataque es ciego. El atacante va a estar suplantando la identidad de un trusted-host para poder saltarse la seguridad del host objetivo. El trusted-host se desactiva empleando el mΘtodo explicado abajo. Lo que el host objetivo cree es que estß manteniendo una conversaci≤n con otro colega. En realidad, el atacante estß sen-tado en alguna oscura esquina de Internet, falsificando paquetes desde este trusted-host mientras estß enfrascado en una batalla de DoS (denial of service). Los datagramas IP enviados con la direcci≤n IP falsificada alcanzan su objetivo sin problemas (recordemos que IP es un protocolo "sin conexi≤n" , cada datagrama es enviado sin tener en cuenta lo que pase con el otro extremo) pero los datagramas que el host objetivo envφa de vuelta (destinados al trusted-host) se van a la mierda. El atacante nunca los ve. Los routers que intervienen onocen
d≤nde se supone que tienen que ir los datagramas. Se supone que van hacia el trsuted-host. En lo que respecta al nivel de red, desde aquφ es desde d≤nde fueron originados y ahφ es donde deberφan ir las contestaciones. Por supuesto una vez que los datagramas son enrutados hacia allφ y la infor-maci≤n es desmultiplexada y llega al TCP, se desecha (el TCP del trusted-host no puede responder --ver abajo). Por lo tanto el atacante tiene que ser inteligente y *saber* quΘ fue enviado, y
*saber* quΘ respuesta estß buscando el server. El atacante no puede ver lo que el host objetivo le envφa, pero puede *predecir* lo que le enviarß; eso unido al conocimiento con certeza de lo que *enviarß*, le permite al atacante librarse de esta "ceguera".
--[ Encontrando Trusted-Hosts]--
DespuΘs de elegir un objetivo el atacante debe averiguar los posibles trusted-hosts disponibles (por el bien de todo esto, daremos por hecho que el host objetivo *SI* confφa en alguien. Si no es asφ, el ataque se acaba-rφa aquφ). Averiguar en quiΘn confφa un host puede no ser fßcil. Un "showmount -e" puede mostrarte a d≤nde se exportan los archivos del sistema, y rcpinfo tambiΘn puede ofrecerte informaci≤n interesante. Si se tiene abundante informaci≤n sobre el host, no deberφa ser difφcil. Si todo esto falla, probar direcciones IP vecinas en un esfuerzo de fuerza bruta puede ser una opci≤n viable.
--[ Desactivaci≤n del Trusted-Host Empleando Synflooding ]--
Una vez que hemos encontrado el trusted-host, debemos desactivarlo. Dado que el atacante va a hacerse pasar por Θl, debe asegurarse de que este host no reciba ning·n trßfico de la red y nos fastidie las cosas. Existen muchas maneras para hacer esto, la que voy a explicar es el TCP SYN flooding.
Una conexi≤n TCP se inicia cuando un cliente hace una petici≤n a un server con el SYN flag activado en la cabecera TCP. Normalmente el server devolverß un SYN/ACK al cliente identificado por la direcci≤n de 32-bits en la cabecera IP. El cliente enviarß entonces un ACK al server (como veφamos en la figura 1 al principio) y la transferencia de datos podrß comenzar.Sin embargo, existe un lφmite mßximo de las peticiones de SYN concurrentes que TCP puede procesar para una determinada conexi≤n. Este lφmite se denomina "backlog" y es la longitud de la cola donde se almacenan las conexiones entrantes (por tanto todavφa
incompletas). Este lφmite de la cola tiene en cuenta el n·mero de conexiones incompletas (el saludo de 3 direcciones estß incompleto) y el n·mero de conexiones completadas que han sido sacadas de la cola por la aplicaci≤n correspondiente por medio del sistema de llamada accept(). Si este lφmite "backlog" se alcanza, TCP desecharß en silencio todas las peticiones de SYN hasta que las conexiones pendientes puedan ser resueltas. Este es el quid de la cuesti≤n.
El host atacante envφa varias peticiones de SYN al puerto TCP que se desea desactivar. Este host tambiΘn debe asegurarse de que la direcci≤n-IP del origen sea cambiada por otra, en este caso un host inalcanzable (el TCP del host objetivo enviarß su respuesta a esta direcci≤n. (IP puede informar al TCP de que el host no es alcanzable, pero TCP considera que estos errores son temporales y deja la resoluci≤n de ellos al IP (reen-rutar los paquetes, etc.) , quien en efecto los ignora). La direcci≤n-IP debe ser inalcanzable porque el atacante no desea que ning·n host reciba los SYN/ACKs que llegarßn enviados por el TCP del host objetivo (si lo anterior sucediese, darφa como resultado un RST que se enviarφa al TCP del host objetivo, lo que anularφa nuestro ataque). El proceso es asφ:
fig(2)
1 Z(x) ---SYN---> B
Z(x) ---SYN---> B
Z(x) ---SYN---> B
Z(x) ---SYN---> B
Z(x) ---SYN---> B
...
2 X <---SYN/ACK--- B
X <---SYN/ACK--- B
...
3 X <---RST--- B
En (1) el host atacante envφa un gran n·mero de peticiones SYN al objetivo (recuerda que el objetivo en esta fase del ataque es el "trusted-host") para llenar su cola de backlog con conexiones pendientes.
(2) El host objetivo responde con SYN/ACKs a lo que Θl cree es el origen de los SYNs que le llegan. Durante todo esto todas otras peticiones a este puerto TCP serßn ignoradas.
Diferentes implementaciones de TCP poseen tama±os de backlog distintos. BSD generalmente tiene un backlog de 5 (Linux tiene un backlog de 6). Pero ademßs existe un `gracioso┤ margen de 3/2. Esto es, TCP permitirß un n·mero de conexiones de hasta backlog*3/2+1. Esto harß posible una conexi≤n incluso si el backlog se±ala 0.
Nota-del-Autor:[ Para un anßlisis mßs exhaustivo del TCP SYN flooding, leer mi trabajo sobre este tema. Cubre el proceso completo al detalle, con teorφa y prßctica. Estß acompa±ado de c≤digo para su funciona-miento, un anßlisis estadφstico y mßs.
B·scalo en el n·mero 49 de Phrack. -daemon9 6/96]
--[ Muestreo de los N·meros Secuenciales y Predicci≤n ]--
Ahora el atacante necesita hacerse una idea de d≤nde se encuentra el TCP del host objetivo de entre el espacio de la secuencia numΘrica de 32-bits. El atacante conecta a un puerto TCP del host objetivo (SMTP es una buena elecci≤n) justo antes de lanzar el ataque y completa el "saludo" de 3 direcciones con dicho host. El proceso es exactamente como en la fig(1), excepto que el atacante guardarß el valor del ISN enviado por el host objetivo. Muchas veces, este proceso se repite
varias veces y el ·ltimo ISN enviado se almacena. El atacante necesita saber cußl es el RTT (round-trip time, tiempo de ida/vuelta) desde el objetivo a su host. (El proceso puede repetirse varias veces, y se calcula una media de todos los RTTs hallados). El RTT es necesa-rio para poder predecir con seguridad el siguiente ISN. El atacante tiene un punto de referencia (el ·ltimo ISN enviado) y conoce tambiΘn c≤mo funciona el incremento de los n·meros secuenciales (128.000/segundo y 64.000 por cada connect) y ahora tiene una idea bastante aproximada de cußnto tardarß un datagrama IP en viajar por Internet hasta alcanzar al objetivo (aproximadamente la mitad del RTT, dado que la mayorφa de las veces las rutas son simΘtricas). DespuΘs de que el atacante haya conseguido esta informaci≤n, inmediata-mente se procede a la siguiente fase del ataque (si otra conexi≤n TCP llegase a alg·n puerto del objetivo antes de que el atacante haya podido continuar con el ataque, el ISN real tendrφa una diferencia de 64.000 con el ISN previsto).
Cuando el segmento spoofeado recorre su camino hasta el objetivo, pueden pasar varias cosas dependien-do de la exactitud de la predicci≤n del atacante:
- Si el n·mero secuencial estß EXACTAMENTE donde el TCP receptor espera que estΘ, los datos que llegan serßn colocados en la siguiente posici≤n disponible del b·ffer receptor.
- Si el n·mero secuencial es MENOR que el valor esperado el byte de datos se considera como una repetici≤n de la transmisi≤n, y es desechado.
- Si el n·mero secuencial es MAYOR que el valor esperado pero todavφa dentro de los lφmites de la capacidad del b·ffer, el byte de datos se considera que es un byte futuro, y es controlado por el TCP, pendiente de la llegada de los bytes que faltan antes que Θl. Si llega un segmento con un n·mero secuencial MAYOR que el valor esperado y que NO estß dentro de los lφmites de la capacidad del b·ffer el segmento es excluido, y TCP enviarß un segmento de respuesta con el n·mero secuencial esperado*.
--[ Alteraci≤n... ]--
Aquφ es donde empieza la parte mßs emocionante del ataque:
fig(3)
1 Z(b) ---SYN---> A
2 B <---SYN/ACK--- A
3 Z(b) ---ACK---> A
4 Z(b) ---PSH---> A
[...]
El host atacante spoofea su direcci≤n-IP para que sea la del "trusted-host" (el cual todavφa deberφa estar sufriendo los efectos del ataque de D.O.S , denial of service) y envφa su petici≤n de conexi≤n al puerto 513 del host objetivo (1). En (2), el host objetivo responde a la petici≤n de conexi≤n spoofeada con un SYN/ACK, que recorrerß su camino hasta el trusted-host (el cual, si *pudiera* procesar este segmento entrante, lo considerarφa un error, e inmediatamente envφa un RST al host objetivo). Si todo va de acuerdo con lo previsto, el SYN/ACK serß ignorado por el trusted host. DespuΘs de (1), el atacante puede descansar un poco para darle tiempo al host objetivo para enviar el SYN/ACK (el atacante no puede ver este segmento). Entonces, en (3) el atacante envφa un ACK al host objetivo conteniendo el n·mero secuencial previsto (mßs uno, porque estamos ACKeßndolo). Si el atacante acierta en su predicci≤n, el host objetivo aceptarß el ACK. El host objetivo establece la conexi≤n y la transferencia de datos puede comenzar (4).
Generalmente, despuΘs de establecer la conexi≤n , el atacante insertarß una backdoor en el sistema que le permitirß llevar a cabo nuevas intrusiones de una manera mßs fßcil. (Con un `cat + + >> ~/.rhosts┤ suele bastar. Esta es una buena idea por varias razones: es rßpido, permite accesos mßs simples, y no es interacti-vo. Recuerda, el atacante no puede ver el trßfico que proviene del host objetivo, por lo tanto todas las respuestas caerßn en el olvido).
--[ Por QuΘ Funciona ]--
El IP-Spoofing funciona porque los servicios de trust entre ordenadores (como los "trusted-hosts") solamente basan su seguridad en autentificaciones de las direcciones de red. Dado que el IP es fßcilmente enga±able, la falsificaci≤n de direcciones no es difφcil. La parte mßs complicada del ataque es la predicci≤n de los n·meros secuenciales, porque es ahφ donde las suposiciones y conjeturas entran en escena. Reducir las dudas y las adivinanzas al mφnimo es bßsico para tener mßs
posibilidades de Θxito. Incluso un sistema que utilice los TCP wrappers de Wietse Venema es vulnerable al ataque. Los TCP wrappers se basan en los hostnames o en direcciones-IP para las autentificaciones de los usuarios...
[ SECCI╙N III. MEDIDAS PREVENTIVAS ]
...Mßs vale prevenir que curar...
--[ No Confiar en Nadie ]--
Una sencilla soluci≤n para prevenir este ataque es no utilizar la autentificaci≤n basada en direcciones. Desactivar los comandos r*, borrar todos los archivos .rhosts y vaciar el archivo /etc/hosts.equiv. Esto forzarß a todos los usuarios a emplear otras medidas de acceso remoto (telnet, ssh, skey, etc.)
--[ Filtrado de Paquetes ]--
Si tu host tiene una conexi≤n directa a Internet, puedes utilizar tu router para ayudarte. Primero aseg·rate de que ·nicamente hosts de tu propia LAN interna pueden participar en relaciones de trust (ning·n host interno debe ser trusted-host de otro sistema externo a la LAN, o viceversa). Entonces simplemente filtra *todo* el trßfico desde fuera (desde Internet) que desea llegar hasta el interior (a tu LAN).
--[ MΘtodos Criptogrßficos ]--
UN mΘtodo obvio para evitar el IP-spoofing es obligar a que todo el trßfico de la red sea encriptado y/o autentificado. Mientras se debaten otras posibles soluciones, puede establecerse Θsta como medida estandar de seguridad.
--[ N·mero Secuencial Inicial Aleatorio ]--
Dado que los n·meros secuenciales no son escogidos aleatoriamente (o incrementados aleatoriamente) el ataque funciona. Bellovin aporta un parche para TCP que implica una partici≤n del espacio dedicado al n·mero secuencial. Cada conexi≤n tendrφa su propio espacio separado de n·mero secuencial. Los n·meros secuenciales serφan incrementados como antes, sin embargo, no habrφa ninguna relaci≤n obvia o apreciable entre la numeraci≤n en estos espacios. Se sugiere la f≤rmula siguiente:
Donde M es el cron≤metro de 4 microsegundos y F es un hash criptogrßfico. F no debe ser calculable desde el exterior o el atacante podrφa todavφa averiguar la secuencia numΘrica. Bellovin sugiere que F sea un hash de el id de la conexi≤n y un vector secreto (un n·mero aleatorio, o un n·mero de host secreto relacionado combinado con el tiempo que lleva encendida la mßquina).
[ SECCI╙N IV. RECURSOS ]
- Libros: TCP/IP Ilustrado, vols. I, II & III
- RFCs: 793, 1825, 1948
- Gente: Richard W. Stevens, y los usuarios de Information Nexus.
- C≤digo disponible: rbone, mendax, SYNflood
Este documento fue posible gracias a una beca de Guild Corporation.
